home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 686 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.4 KB
  1. Subject: Re: First Vote 
  2. Date: Tue, 05 Jul 1994 11:01:33 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. Timothy Miller wrote:
  7.  
  8. >There was discussion of busy-waiting... well, SOMETHING has to busy wait, 
  9. >whether it's your app with a timer or 1-pixel rectangle, or it's the OS 
  10. >which is given only mouse coordinates.
  11.  
  12. Incorrect.  Potentially, the AES can use a centralized rectangle sorting
  13. algorithm, thus only checking a small number of rectangles.
  14.  
  15.  
  16. >When you use rectangles, the OS 
  17. >has to check the position of the mouse against the rectangles for every 
  18. >mouse movement.  I wouldn't think that would have a whole lot less 
  19. >overhead than having your program track a 1-pixel rectangle.
  20.  
  21. Of COURSE it is!  If EVERY APPLICATION is asking the AES to tell it whenever
  22. the mouse moves by 1 pixel, **then doing a objc_find whenever it does**, the
  23. system will crawl to a halt whenever the mouse moves!  By intelligently
  24. choosing a rectangle (or 2) that it a larger equivalence class of mouse
  25. positions (ie. positions for which objc_find results in the same value),
  26. you'll reduce the number of objc_find calls by a factor of 100!  Also,
  27. with a 1-pixel tracking scheme, the faster the machine (eg. Medusa), the
  28. more CPU is burned doing objc_finds (since more mouse motions will be
  29. caught - on a slow machine, the mouse might move 100 pixels between events,
  30. thus losing the maximal-rectangle advantage).
  31.  
  32.  
  33. --
  34. Warwick
  35.